Method and apparatus for implementing a mobile server

ABSTRACT

Methods and apparatus are provided for transmitting data to a client device from a computer module in a vehicle. Data is transmitted from the computer module over an in-vehicle network to an in-vehicle communications gateway module. The data from the computer module is destined for the client device. A request for a software component is transmitted to the client device from a standard port of the in-vehicle communications gateway module. The software component comprises a non-standard transfer protocol module. The in-vehicle communications gateway module loads the non-standard transfer protocol module, and the data is exchanged between the in-vehicle communications gateway module and the client device according to the non-standard transfer protocol.

TECHNICAL FIELD

Embodiments of the present invention generally relate to telematics, andsome embodiments more particularly relate to implementing a mobileserver for communicating data between a client device and a computermodule in a vehicle.

BACKGROUND OF THE INVENTION

A telematics system is one that provides information to or from a mobilesource (e.g., a vehicle), and often describes vehicle systems thatcombine GPS and cellular technologies with onboard electronics whichallow a vehicle to provide information to a remotely located clientdevice or to access numerous telematics services provided a remotelylocated client device. Telematics services can include safety,communication, vehicle diagnostic and entertainment features.

Desirable features and characteristics of the present invention willbecome apparent from the subsequent detailed description and theappended claims, taken in conjunction with the accompanying drawings andthe foregoing technical field and background.

SUMMARY OF THE INVENTION

A method is provided for transmitting data to a client device from acomputer module in a vehicle. Data is transmitted from the computermodule over an in-vehicle network to an in-vehicle communicationsgateway module. The data from the computer module is destined for theclient device. A request for a software component is transmitted to theclient device from a standard port of the in-vehicle communicationsgateway module. The software component comprises a non-standard transferprotocol module. The in-vehicle communications gateway module loads thenon-standard transfer protocol module, and the data is exchanged betweenthe in-vehicle communications gateway module and the client deviceaccording to the non-standard transfer protocol.

An in-vehicle communications gateway module is provided which isdesigned to receive data from a computer module over an in-vehiclenetwork. The data from the computer module is destined for a remoteclient device. The in-vehicle communications gateway module comprises aserver which is designed to transmit, from a standard port of thein-vehicle communications gateway module, a request for a softwarecomponent to the client device. The software component comprises anon-standard transfer protocol module. When the in-vehiclecommunications gateway module receives the software component from theclient device, the in-vehicle communications gateway module closes thestandard port before exchanging the data with the client device so thatstandard internet protocols are not used for the subsequent exchange ofthe data between the server and a browser application hosted at theremote client device. The in-vehicle communications gateway module loadsthe non-standard transfer protocol module, and establishes a connectionwith the client device according to the non-standard transfer protocol.The server then exchanges the data with the client device according tothe non-standard transfer protocol.

A vehicle is provided which comprises a computer module designed togenerate data destined for a remote client device, an in-vehiclenetwork, and an in-vehicle communications gateway module. The in-vehiclecommunications gateway module is designed to: receive the data from thecomputer module over the in-vehicle network, and transmit a request fora software component to the client device from a standard port of thein-vehicle communications gateway module. The software componentcomprises a non-standard transfer protocol module. Upon receiving thesoftware component, the in-vehicle communications gateway module loadsthe non-standard transfer protocol module, and exchanges the data withthe client device according to the non-standard transfer protocol.

DESCRIPTION OF THE DRAWINGS

The present invention will hereinafter be described in conjunction withthe following drawing figures, wherein like numerals denote likeelements, and

FIG. 1 is a block diagram of a telematics communication networkincluding a remote client device and a vehicle;

FIG. 2 is a standard protocol stack used for exchanging data between theclient device and the in-vehicle communications gateway module accordingto a conventional approach;

FIG. 3 is a simplified message flow diagram for communicating data tothe remote client device from a server at the in-vehicle communicationsgateway module according to one conventional approach;

FIG. 4 is a simplified message flow diagram for exchanging data betweenthe client device and the in-vehicle communications gateway module whenthe client device requests data from an in-vehicle computer module inaccordance with some embodiments of the invention;

FIG. 5 is an exemplary non-standard transfer protocol stack used forexchanging data between the client device and the in-vehiclecommunications gateway module in accordance with some embodiments of theinvention;

FIG. 6 is a simplified message flow diagram for exchanging data betweenthe remote client device and the in-vehicle communications gatewaymodule when an in-vehicle computer module pushes data to the remoteclient device in accordance with other embodiments of the invention;

FIG. 7 is a simplified message flow diagram for exchanging data betweena remote server device and an in-vehicle communications gateway modulein accordance with some embodiments of the invention when an in-vehiclecomputer module requests data from the remote server device; and

FIG. 8 is a simplified message flow diagram for exchanging data betweenan in-vehicle communications gateway module and a remote client devicewhen the remote client device requests data from an in-vehicle computermodule in accordance with other embodiments of the invention.

DESCRIPTION OF AN EXEMPLARY EMBODIMENT

The following detailed description is merely exemplary in nature and isnot intended to limit the invention or the application and uses of theinvention. Furthermore, there is no intention to be bound by anyexpressed or implied theory presented in the preceding technical field,background, brief summary or the following detailed description. Anyembodiment described herein is not necessarily to be construed aspreferred or advantageous over other embodiments. All of the embodimentsdescribed in this detailed description are illustrative provided toenable persons skilled in the art to make or use the invention and notto limit the scope of the invention which is defined by the claims.

Before describing in detail embodiments that are in accordance with thepresent invention, it should be observed that the embodiments resideprimarily in combinations of method steps and apparatus componentsrelated to communicating data between a client device and a computermodule in a vehicle. Accordingly, the apparatus components and methodsteps have been represented where appropriate by symbols in thedrawings, showing only those specific details that are pertinent tounderstanding the embodiments of the present invention so as not toobscure the disclosure with details that will be readily apparent tothose of ordinary skill in the art having the benefit of the descriptionherein.

In this document, relational terms such as first and second, and thelike may be used solely to distinguish one entity or action from anotherentity or action without necessarily requiring or implying any actualsuch relationship or order between such entities or actions. The terms“comprises,” “comprising,” or any other variation thereof, are intendedto cover a non-exclusive inclusion, such that a process, method,article, or apparatus that comprises a list of elements does not includeonly those elements but may include other elements not expressly listedor inherent to such process, method, article, or apparatus. An elementproceeded by “comprises . . . a” does not, without more constraints,preclude the existence of additional identical elements in the process,method, article, or apparatus that comprises the element.

It will be appreciated that embodiments of the invention describedherein may be comprised of one or more conventional processors andunique stored program instructions that control the one or moreprocessors to implement, in conjunction with certain non-processorcircuits, some, most, or all of the functions for communicating databetween a client device and a computer module in a vehicle, as describedherein. The non-processor circuits may include, but are not limited to,a radio receiver, a radio transmitter, signal drivers, clock circuits,power source circuits, and user input devices. As such, these functionsmay be interpreted as steps of a method for communicating data between aclient device and a computer module in a vehicle. Alternatively, some orall functions could be implemented by a state machine that has no storedprogram instructions, or in one or more application specific integratedcircuits (ASICs), in which each function or some combinations of certainof the functions are implemented as custom logic. Of course, acombination of the two approaches could be used. Thus, methods and meansfor these functions have been described herein. Further, it is expectedthat one of ordinary skill, notwithstanding possibly significant effortand many design choices motivated by, for example, available time,current technology, and economic considerations, when guided by theconcepts and principles disclosed herein will be readily designed toallow generating such software instructions and programs and ICs withminimal experimentation.

Terminology

As used herein, the term “vehicle” broadly refers to a non-livingtransport mechanism. Examples of vehicles include automobiles such asbuses, cars, trucks, sport utility vehicles, vans, vehicles that do nottravel on land such as mechanical water vehicles including watercraft,hovercraft, sailcraft, boats and ships, mechanical under water vehiclesincluding submarines, mechanical air vehicles including aircraft andspacecraft, mechanical rail vehicles such as trains, trams and trolleys,etc. In addition, the term “vehicle” is not limited by any specificpropulsion technology such as gasoline or diesel fuel. Rather, vehiclesalso include hybrid vehicles, battery electric vehicles, hydrogenvehicles, and vehicles which operate using various other alternativefuels.

Exemplary Telematics Network

FIG. 1 is a block diagram of a telematics communication network 100including a remote client device 110 and a vehicle 125.

The vehicle 125 includes an in-vehicle communications gateway module 130and a number of computer modules 142, 144, 146 in the vehicle 125. Thein-vehicle communications gateway module 130 communicates with othercomputer modules 142, 144, 146 in the vehicle 125 via an internalvehicle network. The in-vehicle communications gateway module 130communicates with the remote client device 110 via a network such as theInternet or other IP network.

A client device 110 can be, for example, a personal computer, a laptopcomputer, a handheld computer such as a personal digital assistant(PDA), or a wireless communication device such as cellular telephone.While client devices are generally located remotely with respect to thelocation of the vehicle 125, there is no restriction on the location ofthe client device 110. The term “client device” generally refers to anycomputing device which can communicate over an IP network 120 (e.g.,Internet) via a web browser application 112, such as Internet Explorer.Some client devices also include a server 114.

The computer modules 142, 144, 146 can generally be any in-vehiclecomputer module that can receive data, transmit data and/or process ormanipulate data according to a list of instructions. Non-limitingexamples of computer modules include, for example, a power traincontroller module, a body control module, a door control module, akeyless entry module, an anti-lock brake control module, a sensing anddiagnostic module, a instrument panel module, a navigation module, atransfer case control module, a radio module, airbag module, rain sensormodule, etc.

The in-vehicle communications gateway module 130 generally refers to acomputer hardware and/or software modules which serve as a gateway forcommunications to or from one or more remote client devices 110, and forcommunications to or from one or more computer modules 142, 144, 146inside the vehicle 125. The in-vehicle communications gateway module 130can be implemented, for example, using a communications module such as aflexible computer platform module (FCPM), a telematics module, etc.Among other functions, the in-vehicle communications gateway module 130manages interfaces to remote client devices 110, and provides statusupdates between the remote client devices 110 and the computer modules142, 144, 146 inside the vehicle 125.

The in-vehicle communications gateway module 130 also includes a server132 which allows the in-vehicle communications gateway module 130 tocommunicate with the client device 110 over a wired or wireless link122. The destination or origin HTTP server 132 stores or createsresources such as HTML files and images. As used herein, the term“server” refers to a computer that is responsible for accepting requestsfrom clients, which are known as “web browsers,” and serving themresponses along with optional data contents, which usually are web pagessuch as HTML documents and linked objects (images, etc.) or other files.There may be several intermediaries, such as proxies, gateways, andtunnels between the HTTP client and HTTP server. A server typicallyincludes hardware, operating system, server software (IIS, Apache, etc.)that manages requests from the browser and delivers web pages (HTMLdocuments and files) in response, FTP server software for filedownloads, SMTP server software for e-mail service, and site content(e.g., web pages and other files). A server also executes server-sidescripts (CGI scripts, JSPs, ASPs, etc.). If the server is usedinternally and not by the public, it may be called an “intranet server.”

The in-vehicle communications gateway module 130 also includes a clientwith a web browser application 134 which allows the in-vehiclecommunications gateway module 130 to communicate with a server 114running at the client device 110. As used herein, the term “web browser”refers to a software application that enables a user to display andinteract with text, images, and other information typically located on aweb page at a website on the Internet or a local area network. Examplesof web browsers include Internet Explorer, Mozilla Firefox, Safari,Opera, and Netscape. Web browsers communicate with servers to fetchwebpages from servers and/or to submit information to servers. Text andimages on a Web page can contain hyperlinks to other Web pages at thesame or different website. Web browsers allow a user to quickly andeasily access information provided on many Web pages at many websites bytraversing these links. Although browsers are typically used to accessthe Internet, they can also be used to access information provided byservers in private networks or content in file systems.

The in-vehicle communications gateway module 130 can also perform, forexample, wireless connectivity functions, security functions, andprovide many services such as remote reflash, remote diagnostics, mediatransfer to the vehicle, playlists, address books, map updates, softwaremodule updates, etc.

Conventional Mobile Server

Telematics systems have been proposed which allow for an in-vehiclecommunications gateway module 130 to function as a vehicle-side server132 which also acts as a telecommunication controller for in-vehiclecomputer modules 142, 144, 146. For example, U.S. Pat. No. 5,732,074 toCellport Systems discloses using a dedicated controller in the vehicleas a server. In this system, the vehicle-side server 132 acts as agateway to vehicle automotive buses which allow the vehicle 125 toconnect to the Internet 120, and standard transfer protocols are used toexchange information between the vehicle-side server 132 and the remoteclient device 110. As used herein, the term “standard transfer protocol”or “standard Internet protocol” refers to a data exchange protocol whichimplements a HTTP layer over a TCP layer over an IP layer (in that orderas HTTP-over-TCP-over-IP) as part of a protocol stack for exchangingdata between a client and a server, as will now be described below withreference to FIG. 2.

FIG. 2 is a standard protocol stack 200 used for exchanging data betweenthe client device 110 and the in-vehicle communications gateway module130 according to a conventional approach. As used herein, a protocolstack (sometimes also referred to as a communications stack) refers to aparticular software implementation of a computer networking protocolsuite. The protocol suite defines the protocols, and the protocol stackis the software implementation of those protocols.

As illustrated in FIG. 2, the protocol stack 200 includes applicationlayers 205, 210, 215 which include a browser application 205 (e.g.,Internet Explorer), a presentation layer 210 such as HTML, and a sessionlayer 215 where the Hyper Text Transfer Protocol (HTTP) is implemented.As used herein, the term “Hyper Text Transfer Protocol (HTTP)” refers toa request/response protocol between clients and servers which is used totransfer or convey information on the Internet. RFC 2616 (1999) definesHTTP/1.1, the version of HTTP in common use today. The term “server”refers to a computer that is responsible for accepting HTTP requestsfrom clients, which are known as “web browsers,” and serving them HTTPresponses along with optional data contents, which usually are web pagessuch as HTML documents and linked objects (images, etc.) or other files.A server typically includes hardware, operating system, HTTP serversoftware (IIS, Apache, etc.) that manages requests from the browser anddelivers web pages (HTML documents and files) in response.

The protocol stack 200 also includes a transport layer 220 where theTransmission Control Protocol (TCP) is implemented, and an InternetProtocol (IP) layer 230. The Transmission Control Protocol(TCP)/Internet Protocol (IP) protocol suite is the set of communicationsprotocols that implement the protocol stack on which the Internet andmost commercial networks run. The transport layer 220 responds toservice requests from the application layer and issues service requeststo the IP or “Internet” layer 230. TCP ensures reliable and effectivedata transfer by dividing information into pieces and adding destinationaddresses to each piece, while IP uses the address in each piece toroute the piece to a particular destination. In the TCP/IP model, thetransport layer is responsible for delivering data to the appropriateapplication process on the host computers. The transport layer controlsthe reliability of a given link through flow control,segmentation/desegmentation, and error control. This involvesstatistical multiplexing of data from different application processes,i.e. forming data packets, and adding source and destination portnumbers in the header of each transport layer data packet. Together withthe source and destination IP address, the port numbers constitutes anetwork socket, (e.g., an identification address of theprocess-to-process communication). TCP provides end-to-end reliablecommunication (e.g., error recovery by means of error detecting code andautomatic repeat request (ARQ) protocol). The ARQ protocol also providesflow control, which may be combined with congestion avoidance. TCP isused, for example, in HTTP web browsing and email transfer.

The protocol stack 200 also includes a data link layer 240 and aphysical layer 250.

Thus, in the standard protocol stack 200 of FIG. 2, HTTP 215 isimplemented on top of TCP/IP 220, 230. Operation of the conventionalHTTP/TCP/IP protocol stack 200 is well-understood by those skilled inthe art, and will not be described in further detail herein.

FIG. 3 is a simplified message flow diagram 300 for communicating datato the remote client device 110 from a server 132 at the in-vehiclecommunications gateway module 130 according to one conventionalapproach. At step 310, to initiate a session, a browser application 112(or other end-user tool) at the originating HTTP client device 110 sendsa TCP connection request to the in-vehicle communications gateway module130, and at step 320, the client device 110 establishes a TCP connectionto a standard port (e.g., port 80) of the in-vehicle communicationsgateway module 130. Techniques for establishing a TCP connection arewell-known in the art and will not be described further herein.

At step 330, the computer module 142 provides the requested data to HTTPserver 132 at the in-vehicle communications gateway module 130, and atstep 340, the HTTP server 132 serves the data (via standard port 80 ofthe HTTP server 132) to remote HTTP client device 110 according tostandard Internet protocols (e.g. HTTP-over-TCP-over-IP). For purposesof illustration, the data exchanges between 142 and 130 and between 110and 130 are both illustrated using one arrow; however, it will beappreciated that in reality, each of the data exchanges may involve atleast one request, and multiple responses and acknowledgements betweeneach pair of entities. A response to a single request can also sometimesinvolve multiple exchanges between the entities. For example, althoughnot illustrated in FIG. 3, the in-vehicle communications gateway module130 may communicate multiple data requests to the computer module 142,and the computer module 142 may reply back to the in-vehiclecommunications gateway module 130 (via an in-vehicle network) with therequested data.

In a simplified example of data exchange 340, when the HTTP server 132receives a request message from the HTTP client 110, the HTTP server 132sends back a status line, such as “HTTP/1.1 200 OK”, and a message ofits own, the body of which is perhaps the requested file or some otherinformation. For simplicity of illustration, these exchanges are shownusing a single arrow. In addition, it will be appreciated that in manycases the data exchange between the browser application 112 of the HTTPclient device 110 and the HTTP server 132 at the in-vehiclecommunications gateway module 130 typically involves one or more HTTPrequest messages (sometimes referred to as a HTTP_GET messages) from theHTTP client 110 to the HTTP server 132, and a plurality of HTTP replymessages from the HTTP server 132 to the browser 112 (sometimes referredto as a HTTP_(—)200_OK and HTTP_Continue messages with segments of therequested data), and other messages such as acknowledgements (ACKs) fromthe HTTP client 110 to the HTTP server 132 in response to theHTTP_Continue messages. As such, although data exchange 340 isrepresented with a double-headed arrow, those skilled in the art willappreciate that the data exchange between the browser application 112 ofthe HTTP client device 110 and the HTTP server 132 at the in-vehiclecommunications gateway module 130 will likely involve multipleexchanges.

Once the data exchange between the browser application 112 of the HTTPclient device 110 and the HTTP server 132 at the in-vehiclecommunications gateway module 130 is complete, at step 350, the TCPconnection between the remote HTTP client device 110 and the in-vehiclecommunications gateway module 130 is terminated.

Overview of Exemplary Embodiments

Notwithstanding these techniques, it would be desirable to providealternative system and method which do not require the use of “standardtransfer protocols” or “standard Internet protocols” (i.e., aHTTP-over-TCP-over-IP protocol stack) to exchange data between a clientand a server.

In accordance with embodiments disclosed herein, techniques are providedwhich can allow a remote device and an in-vehicle communication gatewaymodule to exchange data without using HTTP-over-TCP-over-IP as thetransfer protocol for exchanging data between those entities. Thisallows for use of particular, non-standard transfer protocols andnon-standard ports during data exchange in a telematics network.

FIG. 4 is a simplified message flow diagram 400 for exchanging databetween the client device 110 and the in-vehicle communications gatewaymodule 130 in accordance with some embodiments of the invention when theclient device 110 requests data from an in-vehicle computer module 142.The scenario in FIG. 4 will be described with reference to a scenariowhere the client device 110 is requesting data from computer module 142in the vehicle 125; however, it will be appreciated that the dataexchange of FIG. 4 is not limited to that specific scenario.

At step 410, the client device 110 sends a TCP connection request to thein-vehicle communications gateway module 130, and at step 420, theclient device 110 and in-vehicle communications gateway module 130establish a TCP connection. For example, in one implementation, thein-vehicle communications gateway module 130 receives a request for aHTTP service from the client device 110 on a standard port (e.g. HTTPport 80) of the in-vehicle communications gateway module 130. Techniquesfor establishing a TCP connection are well-known in the art and will notbe described further herein.

At step 430, browser application 112 of the client device 110 sends anHTTP request message for a software component to the server 132 at thein-vehicle communications gateway module 130. As described below, thesoftware component or “module” includes a particular, non-standardtransfer protocol module stack for use during subsequent datacommunications between browser application 112 of the client device 110and the server 132 at the in-vehicle communications gateway module 130.

At step 440, the in-vehicle communications gateway module 130 sends anHTTP response message to the client device 110 which includes a softwarecomponent. The software component includes algorithms in the form of anexecutable program which include a particular, non-standard transferprotocol stack. The “software component” can be implemented, forexample, using a browser downloadable executable program such as a Javaapplet, an active X control, or a compiled program (if downloaded firstand executed subsequently).

Thus, during this session initiation phase, the server application 132in the in-vehicle communications gateway module 130 is used as astandard web interface. For example, when a remote user initiates asession by entering a URL corresponding to the vehicle 125 into thebrowser application 112 running on the remote client device 110 (e.g.,user types http://10.11.12.13 into a browser application 112 where theimaginary 10.11.12.13 represents the vehicle 125), the server 132 at thevehicle 125 responds with a “web page” which begins the download of thesoftware component from the vehicle 125 to the remote client device 110.

When the in-vehicle communications gateway module 130 sends the softwarecomponent to the remote client device 110, at step 450, the in-vehiclecommunications gateway module 130 and the client device 110 close theirstandard HTTP ports to terminate the HTTP session and release their TCPconnection. This way “standard” internet protocols (the conventionalHTTP/TCP/IP protocol stack of FIG. 2) are not used for the subsequentexchange of information between the in-vehicle communications gatewaymodule 130 and the remote client device 110.

At step 451, the client device 110 loads and executes the softwarecomponent which includes the particular, non-standard transfer protocolmodule. Once executed by the remote client device 110, the particular,non-standard protocol stack allows the remote client device 110 tocommunicate with the in-vehicle communications gateway module 130 usingthe particular non-standard transfer protocol. This way, when thebrowser application 112 loads and executes the executable program andruns it on the remote client device 110, the remote client device 110knows how to communicate with the in-vehicle communications gatewaymodule 130 according to the rules of the particular, non-standardtransfer protocol. As will be described below, the particular,non-standard transfer protocol stack included in the software componentor module can vary greatly depending on the particular implementation.Regardless of the particular implementation, when a “non-standard”transfer protocol is used to exchange data between the in-vehiclecommunications gateway module 130 and the remote device 110, theconventional HTTP/TCP/IP protocol stack of FIG. 2 is not used by thein-vehicle communications gateway module 130 and the remote device 110to exchange data during subsequent communications.

After the client device 110 loads the particular, non-standard transferprotocol stack from the software component, the client device 110 isready to communicate and exchange data with the in-vehiclecommunications gateway module 130 according to the particular,non-standard transfer protocol. At step 452, the client device 110 andthe in-vehicle communications gateway module 130 establish a newconnection according to the particular, non-standard transfer protocol.

At step 456, the in-vehicle communications gateway module 130communicates a data request to the computer module 142, and the computermodule 142 sends the requested data to the in-vehicle communicationsgateway module 130 over an in-vehicle network. Notably, any protocol canbe used to exchange data between the in-vehicle communications gatewaymodule 130 and the computer module 142 (i.e., it is not necessary tofollow the particular, non-standard transfer protocol).

At step 460, the server 132 at the in-vehicle communications gatewaymodule 130 exchanges the data which it received from the computer module142 with the browser application 112 that running at the client device110 in accordance with the particular, non-standard transfer protocol.Once the data exchange is complete (i.e., after the browser application112 that running at the client device 110 receives the data it requestedfrom computer module 142), at step 480, the client device 110 and thein-vehicle communications gateway module 130 close the new connection.

Non-Standard Transfer Protocol

As mentioned above, the software component is used to provide clientdevice 110 with the particular, non-standard transfer protocol modulestack for use during subsequent communications between the in-vehiclecommunications gateway module 130 and the remote client device 110. Theparticular, non-standard transfer protocol module stack allows theclient device 110 to communicate according to the particular,non-standard transfer with the in-vehicle communications gateway module130 and vice-versa.

As used herein, the term “non-standard transfer protocol” generallyrefers to a data exchange protocol other than a standard transferprotocol for exchanging data between a client and a server. Anon-standard transfer protocol stack can generally include one or morelayers/protocols not included in the standard protocol stack illustratedin FIG. 2, and this new layer/protocol can be implemented “in place of”one or more layers/protocols of the standard protocol stack illustratedin FIG. 2 and/or “in addition to” one or more layers/protocols of thestandard protocol stack illustrated in FIG. 2 such that non-standardtransfer protocol stack does not implement HTTP-over-TCP-over-IP as partof the transfer protocol used for exchanging data between a client and aserver. For example, in one implementation of a “non-standard” transferprotocol stack, the protocol stack 200 of FIG. 2 can be modified suchthat it includes one or more new layers or protocols which differ fromthe conventional HTTP/TCP/IP protocol stack of FIG. 2 and/or are notincluded in the conventional HTTP/TCP/IP protocol stack 200 of FIG. 2.

In one, non-limiting implementation of a non-standard transfer protocolstack, one or more layers or protocols can be implemented between HTTPand TCP or between TCP and IP, etc. to implement a non-HTTP/TCP/IP dataexchange protocol.

In another, non-limiting implementation, the HTTP layer used in astandard transfer protocol of FIG. 2 can be replaced with acustom-designed or proprietary protocol that supports connectionoriented request/response messaging with error detection and anautomatic repeat request (ARQ) mechanism to provide end-to-end reliablecommunication (e.g., error recovery by means of error detecting code andautomatic repeat request (ARQ) protocol).

One exemplary implementation of the particular, non-standard transferprotocol module stack will now be described below with reference to FIG.5.

Exemplary Non-Standard Transfer Protocol Stack

FIG. 5 is an exemplary non-standard transfer protocol stack 500 used forexchanging data between the client device 110 and the in-vehiclecommunications gateway module 130 in accordance with some embodiments ofthe invention. The exemplary communications protocol stack 500 includesapplication layers 505, 510, 515 including a browser application (e.g.,Internet Explorer), a presentation layer 510 (e.g., HTML) and a non-HTTPrequest/response protocol layer 515; a transport layer protocol 520(such as TCP, UDP, etc.); an Internet layer 540 which implements theInternet Protocol (IP); a datalink layer 550 which can include mediumaccess control (MAC) and link layer control (LLC) sub-layers (not shown)and which can implement any datalink layer protocol including Ethernetdatalink layer protocol, IEEE 802.11 datalink layer protocol, a cellulardatalink layer protocol, a satellite datalink layer protocol, or anyother wireless datalink layer protocol; and a physical layer 560 whichcan implement any physical layer standard including a cellular networkphysical layer (e.g., UMTS, WCDMA, CDMA, AMPS), a satellite physicallayer, Ethernet, IEEE 802.11, IEEE 802.16 (also known as WiMAX), etc.

FIG. 6 is a simplified message flow diagram 600 for exchanging databetween the remote client device 110 and the in-vehicle communicationsgateway module 130 when an in-vehicle computer module 142 pushes data tothe remote client device 110 in accordance with other embodiments of theinvention. The scenario in FIG. 6 will be described with reference to ascenario where the computer module 142 in the vehicle 125 istransmitting or “pushing” data to the remote client device 110; however,it will be appreciated that the data exchange of FIG. 6 is not limitedto that specific scenario. As noted above, the in-vehicle communicationsgateway module 130 can be implemented as part of a telematics modulewhich is designed to manage communications between the computer module142 inside the vehicle 125 and client devices 110. The in-vehiclecommunications gateway module 130 communicates with the computer module142 using an in-vehicle network. The in-vehicle communications gatewaymodule 130 hosts a server application 132, and the remote client device110 hosts a browser application 112.

At step 605, the computer module 142 transmits or “pushes” data that isdestined for the remote client device 110 to the in-vehiclecommunications gateway module 130 over an in-vehicle network. In otherwords, the computer module 142 sends data that is destined for theremote client device 110 without being requested to send that data.Notably, at step 605, any protocol can be used to exchange data betweenthe in-vehicle communications gateway module 130 and the computer module142 (i.e., it is not necessary to follow the particular, non-standardtransfer protocol).

During initiation of a session between the in-vehicle communicationsgateway module 130 and the remote client device 110, at step 610, theremote client device 110 generates a TCP connection request andtransmits it to a standard port of the in-vehicle communications gatewaymodule 130. When the in-vehicle communications gateway module 130receives the TCP connection request, at step 620, the remote clientdevice 110 and in-vehicle communications gateway module 130 establish aTCP connection.

At step 630, the browser application 134 hosted at the in-vehiclecommunications gateway module 130 sends an HTTP request message to theserver 114 hosted at the remote client device 110 to request a softwarecomponent from the server 114. In response to the HTTP request messagefor the software component, at step 652, the remote client device 110sends an HTTP response which includes the software component to thein-vehicle communications gateway module 130.

When the in-vehicle communications gateway module 130 receives thesoftware component, at step 654, the in-vehicle communications gatewaymodule 130 and the remote client device 110 close their respectivestandard HTTP ports and release their TCP connection. As noted above,this way “standard” internet protocols (i.e., HTTP-over-TCP-over-IP) arenot used for the subsequent exchange of information between thein-vehicle communications gateway module 130 and the remote clientdevice 110.

At step 656, browser application 134 at the in-vehicle communicationsgateway module 130 loads and executes the software component whichincludes the particular, non-standard transfer protocol module, andexecutes an executable program to enable communication between theremote client device 110 and the in-vehicle communications gatewaymodule 130 in accordance with the particular, non-standard transferprotocol. At step 657, the remote client device 110 and the in-vehiclecommunications gateway module 130 establish a new connection accordingto the particular, non-standard transfer protocol.

After loading the particular, non-standard transfer protocol stack fromthe software component, the in-vehicle communications gateway module 130is ready to communicate and exchange data with the remote client device110 according to the particular, non-standard transfer protocol. At step660, the server 132 at the in-vehicle communications gateway module 130exchanges the data (which it received from the computer module 142 overthe in-vehicle network) to the browser application 112 that is runningat the remote client device 110 in accordance with the particular,non-standard transfer protocol. Once the data exchange is complete, atstep 680, the remote client device 110 and the in-vehicle communicationsgateway module 130 close the connection.

FIG. 7 is a simplified message flow diagram 700 for exchanging databetween a remote server device 110 and an in-vehicle communicationsgateway module 130 in accordance with some embodiments of the inventionwhen an in-vehicle computer module 142 requests data from the remoteserver device 110.

At step 705, the computer module 142 transmits a request for data to thein-vehicle communications gateway module 130 over an in-vehicle network.In other words, the computer module 142 unilaterally sends a request tothe in-vehicle communications gateway module 130 to request data fromthe remote server device 110. Notably, at step 705, any protocol can beused to forward the request from the computer module 142 to thein-vehicle communications gateway module 130 (i.e., it is not necessaryto follow the particular, non-standard transfer protocol).

In response to the request for data, a browser application 134 at thein-vehicle communications gateway module 130 initiates a session withthe remote server device 110 by generating a TCP connection request, andtransmitting the TCP connection request from a standard HTTP port of thein-vehicle communications gateway module 130 to the remote server device110 at step 710. The remote server device 110 receives the TCPconnection request at a standard HTTP port of the remote server device110.

At step 720, the remote server device 110 and in-vehicle communicationsgateway module 130 establish a TCP connection. Thus, during sessioninitiation, the in-vehicle communications gateway module 130 is used asa standard web interface.

At step 730, the browser application 134 of in-vehicle communicationsgateway module 130 sends an HTTP request message to the remote serverdevice 110 to request the software from the remote server device 110.

In response to the HTTP request message for the software component, atstep 752, the remote server device 110 sends a HTTP response messagewhich includes the software component to the in-vehicle communicationsgateway module 130. As described above, the software component includesa particular, non-standard transfer protocol module.

When the in-vehicle communications gateway module 130 receives thesoftware component from the remote server device 110, at step 754, thein-vehicle communications gateway module 130 closes its standard HTTPport to terminate the HTTP session and release the TCP connection. Asnoted above, this way “standard” internet protocols (the conventionalHTTP/TCP/IP protocol stack of FIG. 2) are not used for the subsequentexchange of information between the in-vehicle communications gatewaymodule 130 and the remote server device 110.

At step 756, browser application 134 at the in-vehicle communicationsgateway module 130 loads and executes the software component whichincludes the particular, non-standard transfer protocol module, andexecutes an executable program to enable communication with the remoteserver device 110 in accordance with the particular, non-standardtransfer protocol. At step 757, the remote server device 110 and thein-vehicle communications gateway module 130 establish a new connectionaccording to the particular, non-standard transfer protocol, and at step758, the in-vehicle communications gateway module 130 then sends amessage to the remote server device 110 to request a data exchange withthe remote server device 110 according to the particular, non-standardtransfer protocol.

At step 760, the remote server device 110 exchanges the requested data(initially requested by the computer module 142 over the in-vehiclenetwork) with the browser application 134 that is running at thein-vehicle communications gateway module 130 in accordance with theparticular, non-standard transfer protocol. At step 770, the in-vehiclecommunications gateway module 130 provides the requested data which itreceived from the remote server device 110 to the computer module 142.Notably, this exchange between in-vehicle communications gateway module130 and the remote server device 110 does not require use of thenon-standard transfer protocol.

Once the data exchange is complete, at step 780, the remote serverdevice 110 and the in-vehicle communications gateway module 130 closethe new connection.

FIG. 8 is a simplified message flow diagram 800 for exchanging databetween an in-vehicle communications gateway module 130 and a remoteclient device 110 when the remote client device 110 requests data froman in-vehicle computer module 142 in accordance with other embodimentsof the invention. The scenario in FIG. 8 will be described withreference to a scenario where the client device 110 is requesting datafrom a computer module 142 in the vehicle 125; however, it will beappreciated that the data exchange of FIG. 8 is not limited to thatspecific scenario.

At step 810, the remote client device 110 sends a TCP connection requestto the in-vehicle communications gateway module 130, and at step 820,the remote client device 110 and in-vehicle communications gatewaymodule 130 establish a TCP connection. For example, the in-vehiclecommunications gateway module 130 receives a request for a HTTP servicefrom the remote client device 110 on a standard port (e.g. HTTP port) ofthe in-vehicle communications gateway module 130, and the in-vehiclecommunications gateway module 130 and the remote client device 110 thenestablish a TCP connection. Techniques for establishing a TCP connectionare well-known in the art and will not be described further herein.

At step 830, the in-vehicle communications gateway module 130 sends aninstruction to the remote client device 110 to close its standard HTTPport and to obtain (i.e., download) a software component which includesa particular, non-standard transfer protocol module from an on-lineserver 105. At step 832, the in-vehicle communications gateway module130 closes its standard HTTP port to terminate its TCP connection to theremote client device 110. This way “standard” internet protocols are notused for the subsequent exchange of information between the in-vehiclecommunications gateway module 130 and the remote client device 110.

In response to the instruction to download the software component fromthe on-line server 105, at step 834, the remote client device 110 sendsa request to an on-line server 105 for the software component, and atstep 840, the on-line server 105 sends the software component to theremote client device 110. As described above, the software componentincludes the particular, non-standard transfer protocol module.

At step 851, the remote client device 110 loads and executes thesoftware component which includes the particular, non-standard transferprotocol module. After the remote client device 110 loads and executesthe particular, non-standard transfer protocol module from the softwarecomponent, the remote client device 110 is ready to communicate andexchange data with the in-vehicle communications gateway module 130according to the particular, non-standard transfer protocol. At thispoint, the non-standard transfer protocol will be used during subsequentcommunications between the in-vehicle communications gateway module 130and the remote client device 110.

At step 852, the remote client device 110 and the in-vehiclecommunications gateway module 130 establish a new connection accordingto the particular, non-standard transfer protocol.

The in-vehicle communications gateway module 130 communicates the datarequest to the computer module 142, and, at step 858, the computermodule 142 and the in-vehicle communications gateway module 130 exchangethe data over an in-vehicle network. Notably, at step 858, any protocolcan be used to exchange data between the in-vehicle communicationsgateway module 130 and the computer module 142 (i.e., it is notnecessary to follow the particular, non-standard transfer protocolmodule stack).

At step 860, the server 132 hosted at the in-vehicle communicationsgateway module 130 sends the data, which it received from the computermodule 142, to the browser application 112 that running at the remoteclient device 110 in accordance with the particular, non-standardtransfer protocol. Once the data exchange is complete, at step 880, theremote client device 110 and the in-vehicle communications gatewaymodule 130 close the connection.

Thus, numerous embodiments have been described which can allow a remotedevice and an in-vehicle communication gateway module to exchange datawithout using HTTP-over-TCP-over-IP as the protocol for exchanging databetween those entities. This allows for use of particular, non-standardtransfer protocols and non-standard ports during data exchange in atelematics network.

While at least one exemplary embodiment has been presented in theforegoing detailed description, it should be appreciated that a vastnumber of variations exist. It should also be appreciated that theexemplary embodiment or exemplary embodiments are only examples, and arenot intended to limit the scope, applicability, or configuration of theinvention in any way. Rather, the foregoing detailed description willprovide those skilled in the art with a convenient road map forimplementing the exemplary embodiment or exemplary embodiments. Itshould be understood that various changes can be made in the functionand arrangement of elements without departing from the scope of theinvention as set forth in the appended claims and the legal equivalentsthereof.

1. A method for transmitting data to a client device from a computermodule in a vehicle, the method comprising: transmitting data from thecomputer module over an in-vehicle network to an in-vehiclecommunications gateway module, wherein the data from the computer moduleis destined for the client device; transmitting, from a standard port ofthe in-vehicle communications gateway module, a request for a softwarecomponent to the client device, wherein the software component comprisesa non-standard transfer protocol module; loading the non-standardtransfer protocol module at the in-vehicle communications gatewaymodule; and exchanging the data between the in-vehicle communicationsgateway module and the client device according to the non-standardtransfer protocol.
 2. A method according to claim 1, further comprising:sending, in response to the request, the software component from theclient device to the in-vehicle communications gateway module.
 3. Amethod according to claim 1, further comprising: establishing aconnection between the in-vehicle communications gateway module and theclient device according to the non-standard transfer protocol.
 4. Amethod according to claim 1, further comprising: closing the standardport of the in-vehicle communications gateway module and a standard portof the client device before exchanging the data between the in-vehiclecommunications gateway module to the client device according to thenon-standard transfer protocol.
 5. A method according to claim 4,wherein the step of closing the standard port of the in-vehiclecommunications gateway module and a standard port of the client device,comprises: closing the standard port at the in-vehicle communicationsgateway module and the client device before exchanging the data betweenthe in-vehicle communications gateway module to the client deviceaccording to the non-standard transfer protocol so that standardinternet protocols are not used for the subsequent exchange ofinformation between the server application hosted at the in-vehiclecommunications gateway module and the browser application hosted at theremote client device.
 6. A method according to claim 3, furthercomprising: closing the connection between the in-vehicle communicationsgateway module and the client device according to the non-standardtransfer protocol after exchanging the data between the in-vehiclecommunications gateway module to the client device according to thenon-standard transfer protocol.
 7. A method according to claim 1,wherein the software component is used to establish the non-standardtransfer protocol module for communications between a server applicationhosted at the in-vehicle communications gateway module and a browserapplication hosted at the remote client device, and wherein the softwarecomponent comprises: an executable program which includes thenon-standard transfer protocol module which allows the browserapplication hosted at the remote client device to communicate with theserver application hosted at the in-vehicle communications gatewaymodule according to the non-standard transfer protocol module.
 8. Amethod according to claim 7, wherein the browser application executesthe executable program to enable communication between the browserapplication hosted at the remote client device and the serverapplication hosted at the in-vehicle communications gateway module inaccordance with the non-standard transfer protocol module.
 9. A methodaccording to claim 7, wherein the software component comprises at leastone of: a compiled program; a Java applet; and an active X control. 10.A vehicle, comprising: a computer module designed to generate data; anin-vehicle network; and an in-vehicle communications gateway moduledesigned to: receive the data from the computer module over thein-vehicle network, wherein the data from the computer module isdestined for a remote client device, and transmit, from a standard portof the in-vehicle communications gateway module, a request for asoftware component to the client device, wherein the software componentcomprises a non-standard transfer protocol module; load the non-standardtransfer protocol module at the in-vehicle communications gatewaymodule; and exchange the data with the client device according to thenon-standard transfer protocol
 11. A vehicle according to claim 10,wherein the in-vehicle communications gateway module is further designedto: receive the software component from the client device.
 12. A vehicleaccording to claim 10, wherein the in-vehicle communications gatewaymodule is further designed to: establish a connection with the clientdevice according to the non-standard transfer protocol.
 13. A vehicleaccording to claim 10, wherein the in-vehicle communications gatewaymodule is further designed to: close the standard port before exchangingthe data with the client device according to the non-standard transferprotocol.
 14. A vehicle according to claim 13, wherein the in-vehiclecommunications gateway module is further designed to: close the standardport before exchanging the data with the client device according to thenon-standard transfer protocol so that standard internet protocols arenot used for the subsequent exchange of the data between a serverapplication hosted at the in-vehicle communications gateway module and abrowser application hosted at the remote client device.
 15. A vehicleaccording to claim 12, wherein the in-vehicle communications gatewaymodule is further designed to: close the connection between thein-vehicle communications gateway module and the client device accordingto the non-standard transfer protocol after exchanging the data with theclient device according to the non-standard transfer protocol.
 16. Avehicle according to claim 10, wherein the software component is used toestablish the non-standard transfer protocol module for communicationsbetween a server application hosted at the in-vehicle communicationsgateway module and a browser application hosted at the remote clientdevice, and wherein the software component comprises: an executableprogram which includes the non-standard transfer protocol module whichallows the server application hosted at the in-vehicle communicationsgateway module to communicate with the browser application hosted at theremote client device according to the non-standard transfer protocol.17. A vehicle according to claim 16, wherein the browser applicationexecutes the executable program to enable communication between thebrowser application hosted at the remote client device and the serverapplication hosted at the in-vehicle communications gateway module inaccordance with the non-standard transfer protocol.
 18. A vehicleaccording to claim 16, wherein the software component comprises at leastone of: a compiled program; a Java applet; and an active X control. 19.An in-vehicle communications gateway module designed to receive datafrom a computer module over an in-vehicle network, wherein the data fromthe computer module is destined for a remote client device, comprising:a server designed to: transmit, from a standard port of the in-vehiclecommunications gateway module, a request for a software component to theclient device, wherein the software component comprises a non-standardtransfer protocol module; receive the software component from the clientdevice; close the standard port before exchanging the data with theclient device so that standard internet protocols are not used for thesubsequent exchange of the data between the server and a browserapplication hosted at the client device; load the non-standard transferprotocol module; establish a connection with the client device accordingto the non-standard transfer protocol; exchange the data with the clientdevice according to the non-standard transfer protocol.
 20. Anin-vehicle communications gateway module according to claim 10, whereinthe software component is used to establish the non-standard transferprotocol module for communications between a server application hostedat the in-vehicle communications gateway module and a browserapplication hosted at the remote client device, and wherein the softwarecomponent comprises: an executable program which includes thenon-standard transfer protocol module which allows the serverapplication hosted at the in-vehicle communications gateway module tocommunicate with the browser application hosted at the remote clientdevice according to the non-standard transfer protocol, wherein thebrowser application executes the executable program to enablecommunication between the browser application hosted at the remoteclient device and the server application hosted at the in-vehiclecommunications gateway module in accordance with the non-standardtransfer protocol.